home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SGI Varsity Update 1998 August
/
SGI Varsity Update 1998 August.iso
/
docs6.4
/
relnotes
/
c_fe
/
ch5.z
/
ch5
Wrap
Text File
|
1998-07-29
|
24KB
|
792 lines
- 1 -
7.2.1 ANSI C Front-End Release Notes
- 2 -
DDDDooooccccuuuummmmeeeennnntttt NNNNuuuummmmbbbbeeeerrrr 000000007777----1111666655559999----000011110000
5. _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s
Unless otherwise indicated, the following bugs
in release 7.2.1 of the C compiler apply to both
traditional C and ANSI C.
5.1 _K_n_o_w_n__P_r_o_b_l_e_m_s__(_L_i_c_e_n_s_i_n_g_)
+o The MIPSpro C compiler will abort if the
license file directory (/var/flexlm)
contains a cycle formed by symbolic links.
For example:
%ls -l /var/flexlm
lrwxr-xr-x 1 root sys 1 Mar 13 1996 license -> .
-rw-r--r-- 1 root sys 1162 Aug 20 17:09 license.dat
%cc foo.c
Bus error (core dumped)
The solution is to remove the symbolic link
that forms the cycle.
+o Overloaded use of LM_LICENSE_FILE
Although this is not a bug, compiler users
often have environments which specify the
LM_LICENSE_FILE variable with a license
file that contains licenses for other
software. If, however, the compiler
licenses are not installed in this
alternate license file, compilations will
generate the warning message illustrated
below. The remedy is to either not use the
LM_LICENSE_FILE variable or to set it to
its old value followed by a colon (:) and
the file that contains the compiler
licenses.
- 3 -
For Example:
%echo $LM_LICENSE_FILE
/usr/john_doe/license.dat
%cc foo.c
No such feature exists (-5,116:2) No such file or directory
The MIPSpro C Compiler
(license FEATURE string = cc)
requires a license password.
For license installation and trouble shooting
information visit the web page:
http://www.sgi.com/Support/Licensing/install_docs.html
To obtain a Permanent license (proof of purchase
required) or an Evaluation license please
visit our license request web page:
http://www.sgi.com/Products/license.html
or send a blank email message to:
license@sgi.com
In North America, Silicon Graphics' customers may request
Permanent licenses by sending a facsimile to:
(650) 932-0537
or by calling our technical support hotline
1-800-800-4SGI
If you are Outside of North America or you are not a Silicon
Graphics support customer then contact your local support provider.
%setenv LM_LICENSE_FILE /usr/john_doe/license.dat:/var/flexlm/license.dat
%echo $LM_LICENSE_FILE
/usr/john_doe/license.dat:/var/flexlm/license.dat
%cc foo.c
%
+o Cryptic warning message from licensing.
- 4 -
The first line of a warning message that
occurs when a license file exists under
/var/flexlm but does not contain the
compiler license can be misleading. For
completeness the following example
illustrates the entire output when a
license file exists, but a license is not
installed:
%cc foo.c
No such feature exists (-5,116)
The MIPSpro C Compiler
(license FEATURE string = cc)
requires a license password.
For license installation and trouble shooting
information visit the web page:
http://www.sgi.com/Support/Licensing/install_docs.html
To obtain a Permanent license (proof of purchase
required) or an Evaluation license please
visit our license request web page:
http://www.sgi.com/Products/license.html
or send a blank email message to:
license@sgi.com
In North America, Silicon Graphics' customers may request
Permanent licenses by sending a facsimile to:
(650) 932-0537
or by calling our technical support hotline
1-800-800-4SGI
If you are Outside of North America or you are not a Silicon
Graphics support customer then contact your local support provider.
- 5 -
5.2 _K_n_o_w_n__P_r_o_b_l_e_m_s__(_6_4_-_B_i_t__a_n_d__N_3_2__M_o_d_e_)
This section describes problems known to exist
in the 7.2.1 C compiler running in 64-bit and
N32 mode.
5.2.1 _P_r_e_p_r_o_c_e_s_s_o_r
+o A warning is issued about macro
redefinitions, even when the new definition
is lexically identical to the existing
(previous) definition.
5.2.2 _C_o_m_p_i_l_e_r
+o References of the external integer i within
a clause of a function are assigned to
references of the internal declaration of
i. The following program gets incorrect
results if compiled -cckr -64 or -cckr -n32
(Bug #289545).
void func(void)
{
int i=0;
{ extern int i; i = 100; }
if ( i != 0 ){ printf("Error(in func -- i = %d)0, i); exit(1); }
}
extern int i;
void func2(void) { i += 100; }
int main(void)
{
func();
func2();
if ( i == 200 ){ exit(0); }
else{ printf("Error(in main -- i = %d)0, i); exit(1); }
}
+o Redefinition of previously prototyped
functions do not generate a meaningful
warning message. When compiling the
following program a deceptive warning
message gets generated:
- 6 -
%cat t.c
#include <unistd.h>
#include <stdio.h>
int
main(int argc, char *argv[])
{
int opt;
extern int getopt();
opt= getopt(argc, argv, "abc");
return 0;
}
% cc -n32 -fullwarn t.c
"t.c", line 10: remark(1498): no prototype for the call to getopt
opt = getopt(argc, argv, "abc");
^
Actually, the problem is the redefinition
(outside of unistd.h) of getopt() within
the program (Bug #323611).
+o The compiler does not generate a warning
message for redundant globals. For
example, the following program compiles
without error or warning in all modes.
int rg = 0;
int rg;
main()
{
foo(rg);
}
5.3 _K_n_o_w_n__P_r_o_b_l_e_m_s__(_3_2_-_B_i_t__M_o_d_e_)
This section describes problems known to exist
in the 7.2.1 C compiler running in 32-bit mode.
5.3.1 _P_r_e_p_r_o_c_e_s_s_o_r
+o The following is permitted by the _c_f_e
preprocessor:
#undef __STDC__
However, it should be illegal.
- 7 -
+o The source location for ``f()'' in:
# /* some rather
lengthy
and multi-line
comment */
void f(void) {...}
will be wrongly perceived by _c_f_e to begin
at the line where the comment starts, since
the "#" is assumed to be a line-directive
while the whole comment is viewed as a
single space within the line-directive.
This will cause _d_b_x to list the wrong
source lines for statements in the body of
``f()''.
+o The -_w_l_i_n_t option causes an incorrect
``implicit type conversion'' warning when
an enumerator is assigned to an enumeration
variable, and may also cause incorrect
``used before set'' warnings for variables
in the controlling expressions of loops:
void
foo(int *head)
{
enum E {e1, e2, e3} c;
int *p, *nextp;
int i;
/* incorrect warning: "implicit conversion from int to enum" */
c = e1;
/* incorrect warning: "i may be used before set" */
do {i = *(p++);} while (!i);
/* incorrect warning: "nextp may be used before set" */
for (p = head; p; p = nextp) nextp = p;
}
+o There is a problem with constant
propagation in the context of weakextern
definitions. For the source:
- 8 -
#include <stdio.h>
extern int a;
#pragma weak a=b
int b = 3;
main()
{
a = 5;
printf("%d, %d", a, b);
}
the output when compiled without any
optimization (-_O_0) ``5, 5'', as expected,
while with optimization the output is ``5,
3''. The latter is a result of constant
propagation, which reduces the body of
``main()'' to:
printf("%d, %d", 5, b);
thus effectively eliminating the assignment
to ``a'' and its alias ``b''.
5.3.2 _C_o_m_p_i_l_e_r
+o Signed and unsigned ``long long''
bitfields, spanning across a 32-bit (word)
aligned boundary, can only be accessed
through the ``.'' operator when the left-
hand side is an addressable lvalue. This
is a limitation of our compiler front-end
(_c_f_e) implementation and _c_f_e will emit
error messages when this constraint is
violated. In earlier versions of the
compiler, _c_f_e terminated with an assertion
for such expressions.
+o An indexing expression with a complicated
index expression may sometime generate
illegal ucode, which causes _u_g_e_n to core
dump. A workaround is to move the index
expression out and assign it to a temporary
variable, or just change the expression.
The following illustrates the only known
case of this happening:
- 9 -
char board[19];
int capture[2];
setboard (int x)
{
capture[!(board[x])]++; /* Ugen coredumps on this! */
capture[(board[x])?0:1]++; /* This works just fine! */
}
+o A standalone _l_i_n_t is available, but it does
not support the same options and
compilation modes supported by the C
compiler (it supports the the AT&T SVR4
compilation modes, and treats ``long long''
types as ``long''). Unless _l_i_n_t is used to
handle _l_i_n_t-directives, to provide _l_i_n_t_2
diagnostics, or to produce the _l_i_n_t output
files, we instead strongly recommend use of
the -_w_l_i_n_t option with the _c_c command.
This option works with all the other
compiler options and flags, including
compilation in ANSI mode. Note that -_w_l_i_n_t
does not produce the traditional output
files from the _l_i_n_t passes, nor does it
handle _l_i_n_t directives, while it does
provide _l_i_n_t-like diagnostics.
5.4 _K_n_o_w_n _P_r_o_b_l_e_m_s _w_i_t_h _W_o_r_k_a_r_o_u_n_d_s (_6_4-_B_i_t _a_n_d
_N_3_2 _M_o_d_e)
+o -IPA and -g cannot be used on the same
command line. The compiler will
automatically turn off interprocedural
optimizations if -g is specified.
+o -OPT:fast_io=ON gives incorrect results
Under certain circumstances, use of this
flag will lead to incorrect results. (Bug
446782)
+o Use of certain characters reserved by the
front-end will cause the compiler to core
dump. The reserved characters are 0x81 and
0x82. (Bug 480882)
+o The following code does not work when
compiled -mp. It occurs for both -32, and
-n32/-64.
- 10 -
typedef struct {
int widget;
} THING;
typedef struct {
THING part;
} OTHER_THING;
extern void setup();
main()
{
OTHER_THING y;
setup(&y);
#pragma parallel
#pragma local(x)
#pragma shared(y)
{
OTHER_THING x;
x.part = y.part;
}
}
It is possible to work around this problem
by avoiding the use of anonymous structure
types. In other words, put some kind of
name in between struct and the opening
brace of the structure definition, and this
problem goes away.
5.5 _K_n_o_w_n _P_r_o_b_l_e_m_s _w_i_t_h _W_o_r_k_a_r_o_u_n_d_s (_3_2-_B_i_t
_M_o_d_e)
+o In 3.17 and earlier versions of the
compiler, no diagnostics were emitted (by
default) in -_c_c_k_r mode for a function
redeclaration with incompatible parameter
types. This could be highly error-prone,
since an argument could be passed to the
same function in differing ways, dependent
on which declaration were in scope at the
point of call. Consider the following
code:
- 11 -
#include <stdio.h>
int f(float f1, float f2);
f(f1, f2)
float f1, f2;
{
printf("f1=%g, f2=%g0, f1, f2);
}
main()
{
f(17.17, 17.17);
}
The unprototyped function definition
expects float arguments to be promoted to
doubles (64 bits entities), while the call
in fact heeds the prototype and passes the
arguments as floats (32 bits entities).
The values printed will be unpredictable.
To avoid this kind of unexpected behavior
we highly recommend that users compile
their code with -_p_r_o_t_o_t_y_p_e_s in -_c_c_k_r mode.
For redeclarations, where references to
parameters in the function body may access
a different bit pattern than that passed on
the caller site (as in the above example),
we now issue an error in -_c_c_k_r mode. Other
forms of incompatible redeclarations still
pass without any diagnostics. The old
(ccom) compiler sometimes successfully
combined such incompatible redeclarations,
but not always. We therefore found it
sounder to disallow the most blatant forms
of mismatches in this version of the
compiler.
+o Note that _l_i_n_t incorrectly diagnoses a
syntax error for the latter of the
following two declarations for
``XSynchronize'':
typedef int Display;
extern int (*XSynchronize(int*))();
extern int (*XSynchronize(Display*))();
The first form of declaration (without the
typedef) can be used as a workaround for
this particular problem.
+o The compiler will incorrectly diagnose the
last of the initializers in the following
code fragment as an incorrect initializing
- 12 -
expression:
typedef unsigned int size_t;
typedef struct uacdef
{
unsigned int *uacind;
unsigned int *uacaln;
unsigned int *uacrcp;
unsigned int *uaccal;
} uacdef;
size_t uacsiz[] = {
(size_t)&(((uacdef*)0))->uacrcp,
(1&0x40 ? sizeof(uacdef) : (unsigned int)&(((uacdef*)0))->uacrcp),
(1&0x40 ? sizeof(uacdef) : (size_t)&(((uacdef*)0))->uacrcp)
};
The first two forms of initializers may be
used as a workaround for this problem.
+o Benchmarks using computational kernels that
operate on arrays with dimensions of a
modulus of the cache size can cause cache
line thrashing. This condition will usually
manifest in a program taking much longer to
compile than expected, and can be analyzed
further by monitoring system performance
statistics such as I/O use during
compilation. The remedy is to increase the
size of the array by a multiple of the
cache line size. Because cache line size
is fixed for each specific architecture,
check your hardware documentation to see
what applies for your system.
